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2. A set of common structures and an identification scheme used to 
variables in the M]B. This is called the Structure of Management Infor 
and is specified in RFC 1155 [Rose and McCloghrie 1990]. For examp' 
specifies that a Counter is a nonnegative integer that counts from 
4,294,967,295 and then wraps around to 0. 

3. The protocol between the manager and the element, called the Simp' 
Management Protocol (SNMP). RFC 1157 [Case et al. 1990] specifies th« 
This details the format of the packets exchanged. Although a wide 
transport protocol; could be used, UDP is normally used with SNMP. 

These RFCs define what h; now called SNMPvl, or just SNMP, which is the tc 
chapter. During 1993 additional RFCs were published specifying SNMP 
(SNMPv2), which we describe in Section 25.12. 

Our approach to SNMP in this chapter is to describe the protocol between 
ager and the agent first, and then look at the data types for the variables maint 
the agent. We describe the database of information maintained by the agent (t 
looking at the groups that we've described in this text: IP, UDP, TCP, and so 
show examples at each point along the way, tying network management back 
protocol concepts from earlier chapters. 



25.2 Protocol 



SNMP defines only five types of messages that are exchanged between the manag 
agent. 

1. Fetch the value of one or more variables: the get-request operator. 

2. Fetch the next variable after one or more specified variables: 
get-next-requost operator. (We describe what we mean by "next" la 
this chapter.) 

3. Set the value of or.e or more variables: the set-request operator. 

4. Return the value of one or more variables: the get -response operator, 
the message returned by the agent to the manager in response to 
get-request, get-next-request, and set-request operators. 

5. Notify the managtjr when something happens on the agent: the trap operat 

The first three messages are sent from the manager to the agent, and the last two 
from the agent to the manager. (We'll refer to the first three as the get, get-next, 1 
set operators.) Figure 25.1 summarizes these five operators. 

Since four of the five SNMP messages are simple request-reply protocols (the m 
ager sends a request, the agent sends back a reply) SNMP uses UDP. This means I 
request from the manager may not arrive at the agent, and the agent's reply may 
make it back to the manajjer. The manager probably wants to implement a timeout I 
retransmission. 
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Figure 25.1 Summary of the five SNMP operators. 
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Figure 25.2 Format of the five SNMP messages. 




on 25.10 



Traps 385 



stn % snap! -a netb -c secret get ipRouteNextflop. 140.252 .3.0 

ipRouteNextHop . 140 .252.3. 0=140 . 252 .1.6 

This routing table entry tells netb to send the packets to swnrt, which is what we see 
happen. 

Why does gemini send the packets directly back through netb? Because on 
gemini the destination address of the return packets is 140.252.1.29, and that network 
(140.2J52.1) is on a directly connected interface. 

What we're seeing in this example is a policy routing decision. The default route to 
network 140.252.3 is through the router swnrt because gemini is intended to be a mul- 
tihomod host, not a router. This is an example of a multihomed host that does not want 
to be a router. 



Trap* 

AU th€ examples we've looked at so far in this chapter have been from the manager to 
the agent. As shown in Figure 25.1, it's also possible for the agent to send a trap to the 
manager, to indicate that something has happened on the agent that the manager might 
want to know about. Traps are sent to UDP port 162 on the manager. 

In Figure 25.2 we showed the format of the trap PDU. We'll go through all the 
ifields in this message when we look at some tepdump output below. 

Six specific traps are defined, with a seventh one allowing a vendor to implement 
~n enterprisespecific trap. Figure 25.30 describes the values for the trap type in the trap 
~essag;e (Figure 25.2). 



trap 
type 



Name 



Description 



coldStart 
warms cart 
linkDown 



linXUp 



authenticationFailure 
egpNe i ghbor Lo s s 

enterpriseSpecif ic 



Agent is initializing itself. 
Agent is reinitializing itself. 

An interface has changed from the up to the down state 

(Figure 25.18). The first variable in the message 

identifies the interface. 
An interface has changed from the down to the up state 

(Figure 25.18). The first variable in the message 

identifies the interface. 
A message was received from an SNMP manager with an 

invalid community. 
An EGP peer has changed to the down state. The first 

variable in the messages contains the IP address of the 

peer. 

Look in the specific code field for information on the trap. 



Figure 25.30 Trap types. 

can see some traps using tepdump. We'll start the SNMP agent on the system 
ni see it generate a coldStart trap. (We tell the agent to send traps to the host 
Although we're not running a manager on bsdi to handle the traps, we can run 
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tcpdump and see what packets get generated. Recall from Figure 25.1 that a t 
from the agent to the manager, but there is no acknowledgment sent by the m 
we don't need a manage:: to handle the traps.) We then send a request using 
program, but with an invalid community name. This should ge 
authenticate ionFailure trap. Figure 25.31 shows the output. 

1 °-° sun.snmp > bsdi . snmp-trap : C-traps Trap (28) 

E:unix. 1.2.5 [140.252.13.33] coldStart 20 

2 18.86 (18.86) sun.snmp > bsdi.snmp-trap: C=traps Trap (29) 

E:unix.l.2.5 [140.252.13.33] authenticationFal !u 

Figure 25.31 tcpdump output of traps generated by SNMP agent. 

First we notice that both UDP datagrams are from the SNMP agent ( 
printed as the name sump) with a destination port of 162 (printed as thtf 
snrap-trap). 

The notation C=traps is the community name of the trap message. This 1m 
figuration option with the ISODE SNMP agent being used. 

The next notation, Trap (28) in line 1 and Trap (29) in line 2 is the PDU 
length. 

The next field of output for both lines is E : unix ,1.2.5. This is the enterpri 
agent's sysObjectlD. :!t falls under the 1.3.6.1.4.1 node of the tree in Figure 
(iso. org. dod. internet .private. enterprises), so this agent's object idea 
is 1.3.6.1.4.1.4.1.2.5. Its abbreviated name is unix. agents . f ourBSD-isode . 5. 
final number (5) is the ve rsion number of this release of the ISODE agent. This 
prise value identifies the <igent software generating the trap. 

The next field output by tcpdump is the IP address of the agent (140.252.13.33). 

The trap type is printed as coldStart on line 1, and authenticationFal! 
on line 2. These correspond to trap type values of 0 and 4, respectively (Figure 23 
Since these are not enterprise-specific traps, the specific code must be 0, and is 
printed. 

Next comes the timestzmp field, printed as 20 and 1907. This is a TimeTicks val 
representing the number of hundredths of a second since the agent initialized. In 
case of the cold start trap, the trap was generated 200 ms after the agent was initialh _ 
The tcpdump output indicates that the second trap occurred 18.86 seconds after the fl 
one, which corresponds to the printed value of 1907 hundredths of a second, minus 
ms. 

. Figure 25.2 indicates ihat a trap message can contain interesting variables that t 
agents wants to send to tha manager, but there aren't any in our examples. 



25.11 ASN.1 and BER 



The formal specification oi : SNMP uses Abstract Syntax Notation 1 (ASN.l) and the actua 
encoding of the bits in the SNMP messages (Figure 25.2) uses the corresponding Ban 
Encoding Rules (BER). UnJike most texts that describe SNMP, we have purposely left 4 
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This is a communication from the examiner in charge of your application. 
COMMISSIONER OF PATENTS AND TRADEMARKS 

OFFICE ACTION SUMMARY 

□ Responsive to communication(s) filed on 

□ This action is FINAL. 

□ Since this application is in condition for allowance except for formal matters, prosecution as to the merits is closed : - 
accordance with the practice under Ex parte Ouayle, 1935 D.C. 1 1 ; 453 O.G. 213. 

A shortened statutory period for response to this action is set to expire ~3> months viva- 
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1.136(a). 

Disposition of Claims 
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Of the above, claim(s) . is/are withdrawn fr:- - ^nn^-eration. 
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B-Ciaim(s) / -//, MytUj ( .^Cj^r-^^-Z U is.v-. ? rejectad. 

IXj / ,g ^ ^7 ^ \ is/a^ to. 

□ Claims _ are subject to restriclion or pip- ;k*n retirement. 

Application Papers 

&*See the attached Notice of Drattsperson*s Patent Drawing Review, PTO-948. 

□ The drawing(s) filed on — is/are objected to by the Examiner. 

□ The proposed drawing correction, filed on _ is ~\ approved T; disapproved. 

D The specification is objected to by the Examiner. 

□ The oath or declaration is objected to by the Examiner. 
Priority under 35 U.S.C. § 119 

□ Acknowledgement is made of a claim for foreign priority under 35 U.S.C. § 1 19(a)-(d). 

□ All □ Some* □ None of the CERTIFIED copies of the priority documents have been 

□ received. 

□ received in Application No. (Series Code/Serial Number) 

□ received in this national stage application from the International Bureau (PCT Rule 1 7.2(a) V 
'Certified copies not received: ^^^^ 
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□ Interview Summary, PTO-413 
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Claim Rejections - 35 USC §102 

1. The following is a quotation of the appropriate paragraphs 

of 35 U.S.C. 102 that form the basis for the rejections under 
this section made in this Office action: 
A person shall be entitled to a patent unless 

(b) the invention was patented or described in a printed publication in 
this or a foreign country or in public use or on sale in this country, more 
than one year prior to the date of application for patent in the DnUad 
States. 

2. Claims 1-11, 16-22, 26-33 are rejected under 35 

U.S.C. 102(b) as being clearly anticipated by U.S. Patent No. 
5,604,542 to Dedrick. 

As per claims 1, 16, 26 and 27, Dedrick discloses converting 
a plurality of streams of audio and/or visual information into a 
plurality of streams of digital packets (col. 2, lines 38-40), 
routing the stream to one or more users (col. 3, lines 16-18), 
controlling the routing of the packets in response to selection 
signals from the users (col. 3, lines 58-60) and monitoring the 
reception of packets by the users and accumulating records (col. 
4, lines 45-48) . 

As per claims 2, 8, 17, 20, 28 and 32, Dedrick discloses at 
least some advertising in at least one stream of packets (col. 2, 
lines 12-14) . 

As per claims 3, 9, 18, 29 and 33, Dedrick discloses varying 
the content of the advertising information with the identity of 
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the user to whom the advertising information is provided (col. 3 , 
line 65 to col. 4, line 3). 

As per claims 4 and 7, Dedrick discloses the information 
being inserted the stream before the stream is converted into a 
stream of packets (col. 2, lines 12-14). 

As per claims 5 and 30, Dedrick discloses generating an 
audio output and/or a visual display from the stream of packets 
(col. 3, lines 33-37) . 

As per claims 6, 19 and 31, Dedrick discloses storing a 
first stream at a first time and inserting the first stream in a 
second stream received by the user (col. 3, line 67 to col. 4, 
line 3) . 

As per claims 10, 11, 21 and 22, Dedrick discloses the 
records indicate how many users received specific advertising 
information (col. 4, lines 45-47), this information being music 
selections (col. 2, 18-20). 

Claim Rejections - 35 USC § 103 

3. The following is a quotation of 35 U.S.C. 103(a) which forms 
the basis for all obviousness rejections set forth in this Office 
action: 

(a) A patent may not be obtained though the invention is not identically 
disclosed or described as set forth in section 102 of this title, if the 
differences between the subject matter sought to be patented and the prior 
art are such that the subject matter as a whole would have been obvious at 
the time the invention was made to a person having ordinary skill in the 
art to which said subject matter pertains. Patentability shall not be 
negatived by the manner in which the invention was made. 
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4. Claims 13, 14, 24, 25, 34, 35 and 36 are rejected under 35 
U.S.C. 103(a) as being unpatentable over Dedrick. 

As per claims 13, 14, 24, 25, 34, 35 and 36, Dedrick does 
not disclose the limitations of these claims. It is known cc 
compress information at the source and decompress it at the 
destination, selecting the compression algorithm in accordance 
with the content of the information. It would have been obvious 
to a person having an ordinary level of skill in the art at the 
time the invention was made to have modified the system disclosed 
by Dedrick to include these features since they allow for 
efficient transmission of data at a faster rate using less memory 
storage space and selection of the compression algorithm ensures 
a reliable reception with little loss of quality and minimum 
degradation. 

Allowable Subject Matter 

5. Claims 12, 15, 23, and 37 objected to as being dependent 
upon a rejected base claim, but would be allowable if rewritten 
in independent form including all of the limitations of the base 
claim and any intervening claims . 

Conclusion 
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6. The prior art made of record and not relied upon is 
considered pertinent to applicant's disclosure. 

U.S. Patent No. 5,493,514 to Keith et al. discloses Process, 
Apparatus and System for Encoding and Decoding Video Signals. 

7. Any inquiry concerning this communication or earlier 
communications from the examiner should be directed to Mr. Thomas 
Peeso whose telephone number is (703) 305-9784. The examiner can 
normally be reached on Monday -Thursday from 7am to 5pm. The 
examiner can also be reached on alternate Fridays. 

8. If attempts to reach the examiner by telephone are 
unsuccessful, the examiner 1 s supervisor, Mr. Emanuel Voeltz, can 
be reached on (703) 305-9714. The fax phone number for this Group 
is (703) 305-95[64,65] . 

9. Any inquiry of a general nature or relating to the status of 
this application should be directed to the Group receptionist 
whose telephone number is (703) 305-3 800. 



Thomas Peeso 
Patent Examiner 
Art Unit 2414 
15 Jul 97 
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